home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1545 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.2 KB
  1. Path: gate.net!not-for-mail
  2. From: feathers@gate.net (Michael Feathers)
  3. Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.edu,comp.lang.c,comp.lang.c++,comp.lang.modula2,comp.lang.modula3
  4. Subject: Re: Hungarian notation
  5. Followup-To: comp.lang.eiffel,comp.lang.ada,comp.edu,comp.lang.c,comp.lang.c++,comp.lang.modula2,comp.lang.modula3
  6. Date: 11 Jan 1996 08:01:34 -0500
  7. Organization: CyberGate, Inc.
  8. Message-ID: <4d31ne$2m6@hopi.gate.net>
  9. References: <30C40F77.53B5@swsbbs.com> <30EF0415.6FE1@tus.ssi1.com> <1996Jan7.045815.8676@ohstpy> <4cpb00$nqk@news.xmission.com> <4crm6i$24mi@navajo.gate.net> <4csi2t$gsa@news.xmission.com> <4ctomq$1pi8@hopi.gate.net> <4cvhga$5rn@news.xmission.com>
  10. NNTP-Posting-Host: hopi.gate.net
  11. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  12.  
  13. Todd Knarr (tknarr@xmission.com) wrote:
  14. : Except that, if you tell people that the prefix on the name tells the
  15. : type of the variable, they may believe you. If they do, in the case
  16. : of my example, they might well say "Oh, the prefix says that's a Stall."
  17. : and merrily proceed to locate the Stall class and begin working with
  18. : it. If they are not intimately familiar with the design of my code
  19. : ( which they may not be, work assignments tend to be handed out based
  20. : on who is available rather than who is most familiar with a given bit
  21. : of code ), they may assume they can trust the prefix to be right and
  22. : skip checking the prototype, the class heirarchy and the like and go
  23. : right to the class that the variable *says* it is rather than finding
  24. : out what it *really* can be. The end result will be, at the very best,
  25. : a simple failure of their changes to work. At worst they'll have a
  26. : 16 megabyte core dump on their hands.
  27.  
  28. It is funny to me that you used references in your example rather than 
  29. pointers.  The problem is equivalent and intrinsic to the nature of 
  30. polymorphism: a reference or pointer can stand for not only a object of
  31. the same type, but of all derived types as well.
  32.  
  33. Funny enough, even in the absence of HN it seems that there would still
  34. be a problem.  Someone would look at the declaration of the reference
  35. and see that "ambiguous" type and could very well be decieved.  Frankly,
  36. I don't see how this deceit that you want to prevent is any more 
  37. compounded if the programmer gleans the type from a HN prefix or the 
  38. variable declaration.  If they don't look at the class hierarchy they
  39. may be screwed nonetheless, by you reasoning.  Personally, I think that 
  40. there are good reasons why this shouldn't happen, but I'll get to them
  41. in a little while.
  42.  
  43. : >Why never a Stall?  If Stall's interface is present in any of its derived
  44. : >classes, Stall calls should be resolved.
  45. : 
  46. : Simple: Stall is merely the base class, and objects of it are *only* created
  47. : during program initialization as a bookkeeping device to keep track of
  48. : information while the program determines the actual current status of the
  49. : shower stall the Stall object represents.
  50. : 
  51. : Once you get into the subclasses, you get serious behavior differences.
  52. : For instance, Stall objects do not respond to changes in the physical stall
  53. : they represent. The routines are there, but they merely return. Each
  54. : subclass implements different behavior to a different set of changes, as
  55. : appropriate.
  56.  
  57. I don't really get the problem.  If your derived Stalls are true 
  58. specializations of the Stall concept, then there are certain operations 
  59. which apply to all Stalls and there are operations which apply only to
  60. specific classes of stalls.  The former should be in the base Stall class
  61. and the latter in each of the derived classes.  If inheritance is used this
  62. way, then any place you have a Stall pointer or reference you should be
  63. performing a valid operation.  If this isn't the case, one could argue 
  64. that the use of inheritance is suspicious.
  65.  
  66. I may be wrong, but do you have services in your base Stall class which 
  67. would more appropriately be in a derived Stall class only?
  68.  
  69. There is alway RTTI.  You could query and then downcast, but I've never
  70. had to do that in practice.
  71.  
  72. Truly, however, HN can work with polymorphism as long as the assumptions 
  73. of polymorphism aren't broken, and the prime assumption is that the methods
  74. available for base classes have reasonable behavior for all derived classes
  75. if you choose to pass around base class pointers and references.
  76.  
  77. -Mike
  78.  
  79.  
  80.